feat(core): info/success/warning/danger variants on json-render Card & Stack - #491
feat(core): info/success/warning/danger variants on json-render Card & Stack#491dvcolomban wants to merge 1 commit into
Conversation
@vitejs/devtools
@vitejs/devtools-kit
@vitejs/devtools-oxc
@vitejs/devtools-rolldown
@vitejs/devtools-vite
@vitejs/devtools-vitest
commit: |
10cff95 to
0471912
Compare
|
Would you explain a bit why you want colored variants on cards and stacks? I don't feel it's a common ui practice tho |
|
Hello, Our immediate need comes from a microfrontend testing panel where developers can override shells, package versions, and import-map entries. The panel can contain dozens of dense rows with package names, URLs, versions, actions, and statuses. We currently represent state with pills, but those pills are easy to lose among the surrounding metadata. This is especially problematic for active or invalid overrides: a developer may otherwise test or debug the application without noticing that the environment has been modified. A subtle Stack tint lets us surface the state at the scope where it applies—the whole row—while keeping the pill or text as the precise, non-color-only indicator. Similarly, a Card tint can communicate that a whole section contains an active override, warning, or error. Beyond our specific panel, these variants could be useful to other information-dense DevTools views where important state competes with a lot of technical metadata: test results, diagnostics, requests, plugins, configuration entries, or dependency inspectors. Cards also have a separate contextual use. A panel may need to render an informational note, warning, success result, or error explanation alongside its main content. Semantic card variants provide a consistent way to express that context without each JSON-render consumer implementing its own alert-like surface. The intention isn't to make cards generally colorful. The variants are opt-in, use restrained surface tints rather than badge-strength fills, and preserve the existing default appearance. They provide additional emphasis when a badge is too local or when the semantic context applies to an entire row or section. We also heavily use tinted info and warning/danger card in our internal documentation tooling and plan on migrating it to a devtool dock panel to co-locate it with the dev environement. For illustration, here a work in progress dock where the information density makes it hard to detect state changes: 
|
…& Stack Extends the variant model from vitejs#477 (which added secondary/ghost/danger) with info/success/warning — new variants entirely, with no prior pixel output to preserve. Also retunes danger: vitejs#477 gave it a flat colored background with a plain grey border, which reads as a mismatch once info/success/warning exist alongside it with a real tinted border, so danger now gets the same treatment as the three new variants instead of staying a fourth "neutral" surface. Each of the four semantic variants (info/success/warning/danger) gets: - a light background tint on the body (Card content, Stack row) - a stronger same-hue tint on Card's header bar, so a titled card reads as a deliberate two-tone surface rather than one flat wash - a matching border, brightened on hover when `interactive` primary/secondary/ghost keep their exact prior background, border (none), and hover behavior — verified via the Card story's Controls panel. Also types Card's and Stack's own props (`CardProps`, `StackProps`) co-located in their component files, and adds `registryProps<Type, Props>()` — a typed alternative to the untyped `props: ['element', 'emit', ...]` array form every registry component currently uses, so `defineComponent` infers `setup`'s `ctx.element.props` as the component's own type instead of `Record<string, any>`. Both types are re-exported from the client webcomponents entry (`@vitejs/devtools/client/webcomponents`, already public) as opt-in strict types.
8c5d315 to
94d0bed
Compare
2 participants
Summary
Continues #477's
variant/interactivework onCard/Stackwith the four semantic hues already used byBadge(info/success/warning/danger):variantSurface(variant)helper intokens.tssoCardandStackread one table instead of duplicating avariantBackgroundmap each.Badge's pill palette (colors) — a badge-strength fill would read as a heavy block over a whole card, so body/header/border/hover alphas are tuned separately.Card's header bar reads a step stronger than its body, so a titled card is a two-tone surface rather than one flat tint.interactivehover strengthens the variant's own border color (not a generic grey) — previously the hover step was indistinguishable from rest for the semantic variants.primary/secondary/ghost/dangerremain pixel-identical to today's look — this is additive.Stack's row variant is independent from its parentCard's variant, and theCardstory now has arowVariantControl so both can be exercised separately.Screenshots
Test plan
pnpm run lintpnpm run typecheckCardstory Controls: cycled all 7 variants ×interactive×rowVariant, confirmedprimary/secondary/ghost/dangerare unchanged fromupstream/main, confirmed hover border is a clearly visible step up from rest for the four semantic variants